Мы довольно часто пишем о максимальных параметрах виртуальной инфраструктуры VMware vSphere и ее компонентов, в частности VMware vCenter (например, тут и тут). Сегодня мы немного освежим эти данные на примере последней версии сервера управления vCenter и приведем несколько примеров. Для начала напомним, что актуальные данные по максимальным конфигурациям продуктов VMware можно найти по адресу: https://configmax.vmware.com, а также в официальной документации.

Кроме того, у VMware есть отличное видео, посвященное лимитам vCenter и правилам выполнения одновременных операций в виртуальной среде:

Итак, лимиты можно разделить на 2 категории:

• Глобальные лимиты для инфраструктуры (виртуальный датацентр).
• Лимиты на уровне хоста и его компонентов (например, сетевые адаптеры).

Если говорить о глобальных параметрах, то значения тут следующие:

• Вы можете запустить до 640 одновременных операций в vCenter, пока они не начнут становиться в очередь.
• Всего можно запустить до 2000 одновременных операций на один сервер vCenter.

На уровне хостов ESXi есть следующие механизмы работы и ограничения:

• Хосты ESXi 6 и 7 версий имеют 16 слотов для выполнения операций в единицу времени:

• Любая операция с виртуальными машинами потребляет какое-то количество слотов на источнике и целевом хосте.
• Операция Storage vMotion стоит 8 слотов на хост. Если вы меняете только датастор у виртуальной машины, оставляя тот же хост, то потребляются эти 8 слотов, то вы можете сделать 2 одновременных миграции. Ранее это работало несколько иначе - смотрите наш пост вот тут.
• Операция Linked clone потребляет 1 слот, но для этого у вас уже должен быть создан снапшот. Если у вас его нет, то он сначала создается - это может замедлить создание первого связанного клона. Также снапшот требуется и при клонировании включенной ВМ, где требуется уже 2 слота (то есть одновременно можно делать 8 таких операций для данной пары хостов).

• Операции Clone, Relocate и vMotion стоят 2 слота каждая на каждом хосте - то есть и на источнике, и на целевом (суммарно получается потребляется 4 слота на двух хостах). Это же работает и при клонировании ВМ на том же самом хосте - на нем в этот момент потребляется 4 слота (то есть одновременно на хосте можно делать 4 таких операции).

Для датасторов также есть слоты и ограничения на одновременные операции:

• У одного датастора есть 128 слотов.
• Операция vMotion стоит 1 слот, то есть на одном датасторе может проходить до 128 одновременных миграций vMotion.
• Операция Storage vMotion стоит 16 слотов, то есть на одном датасторе может проходить до 8 одновременных миграций vMotion.
Это же работает и для датасторов vSAN, где часто встречаются конфигурации с одним датастором - это надо иметь в виду.

Лимиты для сетевых адаптеров сейчас следующие (помните, что для vMotion лучше иметь отдельный адаптер или выделенную пару портов на нем):

• У 1Gb NIC есть 4 слота, то есть можно делать до 4 одновременных миграций vMotion через этот адаптер.
• У 10Gb и 25Gb NIC есть 8 слотов, то есть можно делать до 8 одновременных миграций vMotion через такие адаптеры.

Более подробно об организации адаптеров для vMotion вы можете прочитать в KB 2108824.

Некоторое время назад мы писали о службах VMware vSphere Cluster Services (ранее они назывались Clustering Services), которые появились в VMware vSphere 7 Update 1. Они позволяют организовать мониторинг доступности хостов кластера vSphere, без необходимости зависеть от служб vCenter. Для этого VMware придумала такую штуку - сажать на хосты кластера 3 служебных агентских виртуальных машины, составляющих vCLS Control Plane, которые отвечают за доступность кластера в целом:

Надо отметить, что эти службы обязательны для функционирования механизма динамической балансировки нагрузки в кластере VMware DRS. Если вы выключите одну из виртуальных машин vCLS, то увидите предупреждение о том, что DRS перестанет функционировать:

Иногда требуется отключить службы Cluster Services, что может оказаться необходимым в следующих случаях:

• Вам нужно правильно удалить кластер HA/DRS и выполнить корректную последовательность по выводу его из эксплуатации
• Требуется удалить / пересоздать дисковые группы VMware vSAN, на хранилищах которых размещены виртуальные машины vCLS
• Вам не требуется использовать DRS, и вы хотите отключить эти службы. В этом случае помните, что механизм обеспечения отказоустойчивости VMware HA также будет функционировать некорректно. Он зависит механизма балансировки нагрузки при восстановлении инфраструктуры после сбоя - именно на DRS он полагается при выборе оптимальных хостов для восстанавливаемых виртуальных машин.

Режим, в котором службы Cluster Services отключены, называется Retreat Mode. Итак, заходим в vSphere Client и выбираем кластер, в котором мы хотим ввести Retreat Mode. В строке браузера нам нужна строка вида:

domain ID domain-c<number>

Скопировав эту часть строчки, идем в Advanced Setting сервера vCenter и нажимаем Edit Settings:

Далее создаем там параметр со следующим именем и значением false:

config.vcls.clusters.domain-cxxx.enabled

Где cxxx - это идентификатор домена, который вы скопировали на прошлом шаге:

После этого нажимаем кнопку Save. В консоли vSphere Client в разделе vCLS для кластера мы увидим, что этих виртуальных машин больше нет:

На вкладке Summary мы увидим предупреждение о том, что vSphere Cluster Services больше не работает, а службы DRS вследствие этого также не функционируют корректно:

Чтобы вернуть все как было, нужно просто удалить добавленный параметр из Advanced Settings сервера vCenter.

Недавно компания VMware провела действительно полезный вебинар для администраторов и менеджеров датацентров, в котором рассказала о самых последних лучших практиках по эксплуатации и обслуживанию виртуальной инфраструктуры VMware vSphere 7:

В целом, это видео не только для администраторов, но и для всех тех, кто продает, использует, развертывает, настраивает и управляет решениями VMware на ежедневной основе. В рамках вебинара вы узнаете о некоторых нетривиальных возможностях из богатого набора VMware vSphere 7.x, которые появились после релиза первоначальной версии 7.0.

Например, в видео рассказывается о функциях vSphere Cluster Services (vCLS), переработанных механизмах vMotion и DRS, новых возможностях поддержки GPU для требовательных к графике и CUDA-приложений, а также многих других нововведениях.

В целом, вы узнаете о лучших практиках в следующих сферах:

• Проектирование виртуальной архитектуры
• Развертывание vSphere
• Тюнинг производительности
• Использование средств управления
• Масштабирование инфраструктуры
• Обеспечение отказоустойчивости компонентов виртуальной среды

На днях компания VMware выпустила небольшой апдейт своей флагманской платформы виртуализации VMware vSphere 7.0 Update 3d, включая гипервизор VMware ESXi 7.0 Update 3d и сервер управления VMware vCenter 7.0 Update 3d. Напомним, что прошлое обновление vSphere 7.0 Update 3c, которое исправляло большие проблемы прошлого релиза, компания VMware выпустила в январе этого года.

В ESXi 7 Update 3d появилась поддержка технологии vSphere Quick Boot для следующих платформ:

• Dell Inc. C6420 vSAN Ready Node
• Dell Inc. MX740C vSAN Ready Node
• Dell Inc. MX750C vSAN Ready Node
• Dell Inc. PowerEdge R750xa
• Dell Inc. PowerEdge R750xs
• Dell Inc. PowerEdge T550
• Dell Inc. R650 vSAN Ready Node
• Dell Inc. R6515 vSAN Ready Node
• Dell Inc. R740 vSAN Ready Node
• Dell Inc. R750 vSAN Ready Node
• Dell Inc. R7515 vSAN Ready Node
• Dell Inc. R840 vSAN Ready Node
• Dell Inc. VxRail E660
• Dell Inc. VxRail E660F
• Dell Inc. VxRail E660N
• Dell Inc. VxRail E665
• Dell Inc. VxRail E665F
• Dell Inc. VxRail E665N
• Dell Inc. VxRail G560
• Dell Inc. VxRail G560F
• Dell Inc. VxRail P580N
• Dell Inc. VxRail P670F
• Dell Inc. VxRail P670N
• Dell Inc. VxRail P675F
• Dell Inc. VxRail P675N
• Dell Inc. VxRail S670
• Dell Inc. VxRail V670F

В VMware vCenter 7.0 Update 3d появились следующие улучшения:

• Исправление проблемы безопасности CVE-2022-22948. Более подробно об этом рассказано тут.
• Множество исправлений ошибок, полный список которых приведен тут. Решены проблемы с развертыванием ВМ из OVF-шаблонов, исправлены ошибки с накатыванием инкрементальных патчей vCenter, а также проблема с сообщением о невозможности подключения к серверу Single Sign-On.
• Обновлены компоненты VMware vSphere with Tanzu, подробнее об этом рассказано тут.
• Обновлены компоненты Photon OS, подробнее об этом рассказано тут.

Скачать компоненты VMware vSphere 7.0 Update 3d можно по этой ссылке. Release Notes доступны тут:

• VMware ESXi 7.0 Update 3d
• vCenter Server 7.0 Update 3d

Недавно компания VMware опубликовала интересное тестирование, посвященное работе и масштабированию высокопроизводительных нагрузок (High Performance Computing, HPC) на платформе VMware vSphere 7.

Основной целью тестирования было сравнение нативной производительности HPC-нагрузок на голом железе (bare metal) с работой этих машин на платформе vSphere.

Рабочие нагрузки использовали message passing interface (MPI) с приложениями на базе параллельных процессов (MPI ranks), которые могли объединять несколько физических серверов или виртуальных машин для решения задач. Например, использовались задачи computational fluid dynamics (CFD) для моделирования воздушных потоков в автомобильной и авиа индустриях.

В качестве тестового стенда использовался HPC-кластер из 16 узлов на базе Dell PowerEdge R640 vSAN ReadyNodes в качестве масштабируемых блоков. R640 представлял собой одноюнитовый сервер с двумя процессорами Intel Xeon.

Топология кластера выглядела следующим образом:

• Коммутаторы Dell PowerSwitch Z9332 соединяли адаптеры NVIDIA Connect-X6 на скорости 100 GbE по интерфейсу RDMA для MPI-нагрузок.
• Отдельная пара коммутаторов Dell PowerSwitch S5248F 25 GbE top of rack (ToR) использовалась для сети управления гипервизором, сети vSAN и доступа к ВМ.

Для соединений использовался virtual link trunking interconnect (VLTi). В рамках теста был создан кластер vSAN с поддержкой RDMA.

Конфигурация физических адаптеров выглядела следующим образом:

Вот так выглядит набор HPC-приложений и бенчмарков из разных индустрий, на базе которых проводилось тестирование:

В процессе тестирования производилось масштабирование высокопроизводительного кластера от 1 до 16 узлов, а результаты фиксировались для физической платформы и для виртуальной среды.

Итак, первая задача о динамике жидкостей:

Вторая задача - моделирование прогнозов погоды:

Третья задача - молекулярная динамика (тут на 16 узлах уже есть отличие производительности до 10%):

Еще один бенчмарк по молекулярной динамике, тут тоже есть 10%-е падение производительности на виртуальной платформе, но заметно его становится только при большом количестве узлов:

Бенчмарк NAMD, тут все почти одинаково:

Конечно же, в процессе тестирования производился тюнинг различных настроек самой платформы vSphere и виртуальных машин, вот какие настройки использовались:

Вот так это выглядит в интерфейсе vSphere Client:

Полную версию отчета о тестировании вы можете посмотреть здесь, но из картинок выше вполне понятно, что платформа VMware vSphere и решение vSAN отлично оптимизированы для работы с высокопроизводительными вычислениями.

За последние пару месяцев на сайте проекта VMware Labs вышло несколько обновлений утилиты vSphere Diagnostic Tool. Напомним, что это средство представляет собой python-скрипт, который запускает диагностические команды на виртуальном модуле Photon OS (на его базе построен, например, vCenter Server Appliance), а также в перспективе это будет работать и в среде VMware ESXi. О первой версии vSphere Diagnostic Tool мы писали вот тут.

Основное назначение данной утилиты - дать администраторам быстрое средство траблшутинга, которое они могут использовать для первичной идентификации наиболее распространенных проблем. Если все проверки пройдут успешно, то дальше уже можно более глубоко изучать логи и проводить дополнительные тесты.

Давайте посмотрим, что нового появилось в vSphere Diagnostic Tool (сейчас актуальная версия 1.1.4) с момента ее последнего релиза:

• Исправлены проблемы со спецсимволами в паролях
• Тесты имеют таймаут 10 секунд, а ключ -f используется для пропуска таймаутов
• Название проверки выводится еще до ее запуска
• Проверка VC Disk Space Check теперь игнорирует раздел proc
• Проверка VC Info Check теперь имеет приятный вывод и возможность вывода во внешний канал PSC
• Улучшены проверки VC Core Check
• Исправлено множество ошибок, связанных с обработкой паролей и сертификатов

Скорее всего, данное средство включат в будущем в состав инфраструктурных продуктов линейки VMware vSphere для проверки виртуальных модулей на базе Photon OS (а это уже почти все продукты, построенные на базе хостовой ОС Linux, вроде vCSA).

Скачать утилиту vSphere Diagnostic Tool можно по этой ссылке.

Многие компании сталкиваются сегодня с необходимостью переезжать на другую платформу виртуализации из-за сложностей, связанных с поддержкой зарубежных решений, а также ростом курсов валют. Сегодня мы расскажем об одной из альтернатив, которую предлагает российскому бизнесу компания HOSTVM, и рассмотрим алгоритм миграции на платформу. Сама по себе платформа HOSTVM представляет собой российскую версию гипервизора, построенного на базе открытого исходного кода KVM...

На сайте проекта VMware Labs появилась очередная полезная штука - Solution Designer. Это онлайн-средство для разработчиков и администраторов, которые создают кастомные решения для виртуальной инфраструктуры. При внедрении таких решений часто встают такие задачи, как проверка совместимости различных продуктов VMware и их версий между собой, а также вопросы аппаратной поддержки той или иной платформы.

Данная утилита предоставляет интерактивный интерфейс для решения подобного рода задач. С помощью Solution Designer можно найти наиболее подходящие комбинации версий продуктов VMware, которые гарантированно будут работать друг с другом в рамках построенного проектировщиками решения на базе различных платформ и продуктов.

Также Solution Designer позволяет ввести или импортировать аппаратную конфигурацию оборудования и получить рекомендации по его поддержке со стороны VMware.

Вот как это работает:

Доступ к VMware Solution Designer вы можете получить по ссылке: https://vsd.esp.vmware.com.

На днях компания VMware обновила главный документ о производительности своей флагманской платформы виртуализации - Performance Best Practices for VMware vSphere 7.0, Update 3. Напомним, что с пакетом обновлений Update 3 долгое время были проблемы (в том числе с производительностью), но сейчас доступна стабильная версия этого обновления. Осенью прошлого года мы также писали об этом документе для версии Update 2.

Традиционно документ разбит на 4 больших блока, касающихся оборудования, самой платформы vSphere и серверов ESXi, виртуальных машин, их гостевых систем и средств управления виртуальной инфраструктурой:

• Hardware for Use with VMware vSphere
• ESXi and Virtual Machines
• Guest Operating Systems
• Virtual Infrastructure Management

Подразделы этих глав содержат очень много конкретных пунктов про различные аспекты оптимизации виртуальных датацентров и объектов, работающих в их рамках.

Документ очень полезный, состоит из почти ста страниц и дает просто огромное количество полезной информации для администраторов, одной из главных задач которых является поддержание требуемого уровня производительности виртуальной среды.

Скачать Performance Best Practices for VMware vSphere 7.0, Update 3 можно по этой ссылке.

Компания Principled Technologies выпустила интересное сравнение производительности в контексте плотности размещения виртуальных машин на сервере (VM Density), которое показывает превосходство гипервизора VMware vSphere 7 Update 2 над открытой архитектурой Red Hat OpenShift версии 4.9.

Для тестирования использовались виртуальные машины с полезной нагрузкой SQL Server. С точки зрения оборудования использовался кластер из 5 одинаковых серверов HPE ProLiant DL380 Gen 10, где были размещены ВМ, также для OpenShift дополнительно использовались еще 3 хоста как управляющие узлы.

Первый результат теста - это максимальное число активных виртуальных машин на один узел, которые можно было разместить при обеспечении определенного уровня производительности SQL Server. Тут результат 14-30 в пользу платформы VMware vSphere 7 Update 2:

Также создавали простаивающие виртуальные машины и смотрели, какое их максимальное количество можно разместить на одном хосте, тут тоже vSphere далеко впереди:

В исследовании отдельно подчеркивается, что VMware vSphere имеет также следующие преимущества:

• Механизм обеспечения высокой доступности VMware HA работает более эффективно и проще настраивается
• Рутинные задачи (Day-2) на платформе VMware vSphere выполнять удобнее и быстрее
• Для хостов ESXi можно делать апгрейд хостов без их перезагрузки

Ну и сообщается, что решение vSphere with Tanzu позволяет исполнять нагрузки в контейнерах Kubernetes, которые дополняют серверную инфраструктуру. Больше подробностей вы можете узнать из исследования "VMware vSphere 7 Update 2 offered greater VM density and increased availability compared to OpenShift Virtualization on Red Hat OpenShift 4.9".

Почти два года назад мы писали об особенностях управления сертификатами в обновленной инфраструктуре vSphere 7. Сегодня мы расскажем об управлении сертификатами VMware vSphere с помощью PowerCLI на основе материалов вот этой статьи в блоге VMware.

Все необходимые функции для работы с API по управлению сертификатами были добавлены в PowerCLI версии 12.4 в конце прошлого года, и теперь можно полноценно управлять ими с помощью сценариев.

Вот какие командлеты используются в VMware vSphere 7 (некоторые из них доступны и в более ранних версиях платформы) для получения информации о сертификатах, их добавления и удаления:

• Add-VITrustedCertificate
• Get-VIMachineCertificate
• Get-VITrustedCertificate
• New-VIMachineCertificateSigningRequest
• Remove-VITrustedCertificate
• Set-VIMachineCertificate

Итак, давайте посмотрим, как они работают:

1. Управление доверенным хранилищем сертификатов

Для работы с Trusted Certificate Store можно использовать командлет Get-VITrustedCertificate, который проверяет корневые сертификаты на сервере vCenter Server и/или на присоединенных хостах ESXi (параметры issuer, expiration date, serial number и другие). Вот пример, как проверить хранилища сертификатов на серверах на предмет устаревших сертификатов:

#Check the trusted certificate store of the vCenter and all connected ESXi servers for expired certificates

Get-VITrustedCertificate | Where-Object { $_.NotValidAfter -lt (Get-Date) }

Если мы хотим добавить сертификат или цепочку сертификатов в центр сертификации (certificate authority), который мы используем для хранилища сертификатов, можно использовать командлет Add-VITrustedCertificate:

#Read the certificate or certificate chain from a .pem file

$trustedCertChain = Get-Content "C:\Users\jdoe\Downloads\ca-chain.cert.pem" -Raw



#Add it to the trusted certificate stores of the vCenter and the ESXi servers

Add-VITrustedCertificate -PemCertificateOrChain $trustedCertChain

Также есть командлет Remove-VITrustedCertificate для удаления доверенных сертификатов, которые нам больше не нужны (используйте ее очень осторожно, ведь можно случайно удалить используемый сертификат). В интерфейсе этой функции нет, чтобы администратор случайно не удалил нужные сертификаты из цепочек. Вот как это работает:

Get-VITrustedCertificate -VCenterOnly | `

Where-Object { $_.NotValidAfter -lt (Get-Date) } | `

Remove-VITrustedCertificate

2. Управление SSL-сертификатами компьютеров на сервере vCenter Server

Если у нас есть несколько компьютеров, с которых администраторы получают доступ к vSphere Client, и мы хотим, чтобы сертификаты принимались по умолчанию, мы должны заменить сертификаты на сгенерированные доверенным центром сертификации (trusted certificate authority).

Сначала с помощью этого командлета проверяем текущий сертификат машины vCenter:

Get-VIMachineCertificate -VCenterOnly

После этого создаем запрос на подписку сертификата (certificate signing request, CSR) для vCenter Server. Можно использовать командлет VIMachineCertificateSigningRequest:

$csrParams = @{

Country="US"

Email="jdoe@vmware.com"

Locality="San Francisco"

Organization="My Company"

OrganizationUnit="PowerCLI"

StateOrProvince="California"

}

$csr = New-VIMachineCertificateSigningRequest @csrParams


$csr.CertificateRequestPEM | Out-File "C:\Users\jdoe\Downloads\vc.csr.pem" -Force

После того, как мы получим файл сертификата от центра сертификации, мы можем заменить сертификат машины vCenter с помощью командлета Set-VIMachineCertificate:

$vcCert = Get-Content "C:\Users\jdoe\Downloads\vc.cert.jdoe.pem" -Raw

Set-VIMachineCertificate -PemCertificate $vcCert

Перед установкой SSL-сертификата машины мы должны убедиться, что корневой сертификат нашего CA добавлен в хранилище сертификатов vCenter Server. Помните, что замена сертификата вызовет перезагрузку vCenter.

3. Управление SSL-сертификатами машин для серверов ESXi

Если мы хотим управлять сертификатами полностью самостоятельно, нужно также заменить и сертификаты хостов ESXi. Рабочий процесс в этом случае выглядит несколько сложнее. Сначала нужно изменить настройку режима управления сертификатами хостов ESXi на custom на сервере vCenter и перезагрузить его.

$vCenterConnection = Connect-VIServer vc1.example.com `

-User 'My User' `

-Password 'My Password'

$certModeSetting = Get-AdvancedSetting "vpxd.certmgmt.mode" -Entity $vCenterConnection

Set-AdvancedSetting $certModeSetting -Value "custom"

После этого нужно сгенерировать CSR-запрос для сервера ESXi. Шаг похож на оный для vCenter Server, только нужно будет указать параметр CommonName. Это должно быть FQDN-имя хоста или его IP-адрес. Убедитесь, что CommonName совпадает с идентификатором, по которому вы добавляли этот хост в vCenter.

$esxRequest = New-VIMachineCertificateSigningRequest `

-VMHost $vmhost `

-Country "US" `

-Locality "San Francisco" `

-Organization "My Company" `

-OrganizationUnit "PowerCLI" `

-StateOrProvince "California" `

-CommonName <ESXi host's FQDN> or <ESXi host's IP address>


$esxRequest.CertificateRequestPEM | Out-File "C:\Users\jdoe\Downloads\esx.csr.pem" -Force

Теперь, когда мы получим сертификат от центра сертификации, нужно выполнить 3 операции:

1. Выводим хост в режим обслуживания (maintenance mode) и удаляем его из vCenter:

$vmhost = Get-VMHost 'MyESXiHost' `

Set-VMHost -VMHost $vmhost -State Maintenance

Remove-VMHost $vmhost

2. Соединяемся с хостом ESXi напрямую, устанавливаем там сертификат и перезагружаем хост:

$esxConnection = Connect-VIServer $vmhost.Name `

-User 'My User' `

-Password 'My Password' `

-Force


$esxCertificatePem = Get-Content "C:\Users\jdoe\downloads\myesxcert.pem" -Raw

$targetEsxHost = Get-VMHost $vmhost.Name

Set-VIMachineCertificate -PemCertificate $esxCertificatePem -VMHost $targetEsxHost | Out-Null



Restart-VMHost $targetEsxHost



Disconnect-VIServer $esxConnection

Так же, как и для vCenter, перед установкой сертификата машины нужно убедиться, что корневой сертификат нашего центра сертификации добавлен в доверенное хранилище сертификатов на хосте ESXi и других серверах, с которыми он взаимодействует, то есть остальные хосты ESXi и vCenter.

Снова добавляем наш хост ESXi в vCenter:

$vCenterConnection = Connect-VIServer vc1.example.com `

-User 'My User' `

-Password 'My Password'


$vmhost = Add-VMHost -Name <ESXi host's FQDN> or <ESXi host's IP address> `

-Location (Get-Datacenter "My Datacenter")`

-User "My User" `

-Password "My Password"


$vmhost = Set-VMHost -VMHost $vmhost -State Connected

Ну и остальные идеи вы можете почерпнуть в документе PowerCLI User’s Guide.

Мы уже давно не писали об обновлении утилиты RVTools, предназначенной для помощи администраторам при выполнении рутинных операций с виртуальной инфраструктурой VMware vSphere в различных аспектах. В начале февраля вышло обновление этого средства - RVTools 4.3.1.

Давайте посмотрим, что там нового:

• RVTools теперь использует VMware vSphere Management SDK 7.0U3.
• Новая вкладка vSource, на которой отображается информация о сервере, где исполняется веб-сервис SDK, который используется для сбора данных (это сервер vCenter или хост ESXi).
• Новая колонка Host UUID на вкладке vHost.
• Новые чекбоксы в разделе Health, которые включают/отключают сообщения о безопасности и производительности.
• Раньше колонка UUID заполнялась значениями SMBIOS UUID, которые не уникальны. Теперь там отображается уникальный 128-битный UUID.
• Улучшение производительности при обработке данных.
• На вкладке vHealth появились советы по улучшению производительности ввода-вывода и памяти.
• Исправления ошибок.

Также приведем основные улучшения RVTools с момента выпуска четвертой версии:

• Новая вкладка vUSB, отображающая хосты с присоединенными USB-устройствами.
• Новая вкладка vFileInfo с информацией обо всех файлах на датасторах vSphere (полная информация включается чекбоксом Get fileinfo detail information").
• Log4net обновлен до версии 2.0.12 (защита от уязвимости CVE-2018-1285).
• Отображение информации о том, является ли объект плейсхолдером резервной инфраструктуры VMware SRM.
• Новая колонка Virtual machine tags на вкладках vInfo, vCPU, vMemory, vDisk, vPartition, vCD, vFloppy, vNetwork, vSnapshot, vTools.
• Новая колонка вкладки vInfo: min Required EVC Mode Key.
• Новая колонка вкладки vMemory: Memory Reservation Locked To Max.
• Новые колонки вкладки vRP: Resource Pool path, Resource Pool tags, число ВМ в пуле ресурсов и object ID.
• Новые колонки вкладки vCluster: Cluster tags, custom attributes и object ID.
• Новые колонки вкладки vHost: число ВМ в пуле ресурсов, vSAN Fault Domain Name, Host tags, in Maintenance Mode и in Quarantine Mode.
• Новые колонки вкладки dvSwitch: Distributed VirtualSwitch tags, custom attributes и object ID.
• Новые колонки вкладки dvPort: Distributed VirtualSwitch Port Group tags и object ID.
• Новые колонки вкладки vDatastore: число ВМ в пуле ресурсов, Datastore tags, custom attributes и object ID.
• Новые колонки вкладки vNetwork: ipv4 и ipv6, NIC label, "Internal Sort Column".
• Новые колонки вкладки vDisk: Disk key, disk path, "Internal Sort Column".
• Новые колонки вкладки vPartition: "Internal Sort Column", Disk key.
• Новый чекбокс в настройках "Exclude tags" и параметр CLI -ExcludeTags.
• Объем отображается не в MB, а в MiB.
• Предупреждение о том, что данные собраны не со всех ВМ.

Скачать RVTools 4.3.1 можно по этой ссылке.

В начале февраля компания VMware сообщила, что убрала из списка доступных загрузок дистрибутив своего средства vCenter Converter, которое предназначено для перенесения физических и виртуальных машин с различных платформ в среду VMware vSphere.

Сделано это было из соображений обеспечения совместимости, стабильности и безопасности, так как продукт многие годы не развивается - последний релиз VMware vCenter Conterter был от мая 2018 года (там была и его версия VMware Converter Standalone), хотя, по-сути, не обновлялся он несколько лет до этого. Поддержка этого продукта закончилась в декабре 2019, а последний раз о нем мы упоминали вот тут. Выглядел он тогда так:

Напомним, что для корпоративной инфраструктуры есть средство VMware HCX Enterprise, которое предназначено для переноса виртуальных машин из локального датацентра в облачную инфраструктуру сервис-провайдеров VCPP или публичных облаков, но вот для P2V-миграции внутри датацентра решения от VMware больше нет.

Между тем, VMware заявляет, что работа над новым VMware vCenter Converter ведется, и обязательно будет выпущена его полностью переработанная версия. Сроков пока не называют, поэтому, скорее всего, случится это не раньше конференции VMworld 2022, которая пройдет осенью.

Мы уже писали о том, что на сервере VMware ESXi может возникать ошибка "No space left on device" при выполнении различных операций. Тогда мы объясняли, что такая ситуация может произойти из-за исчерпания числа свободных объектов inodes.

Причина такого поведения может заключаться не только в отсутствии свободных нод. Для начала надо проверить, что проблема действительно не в них. Делается это с помощью команды:

stat -f /

Либо можно использовать также команду df -i.

Если все в порядке с айнодами, то проблема может заключаться в так называемых "small file blocks" (SFB) и "large file blocks" (LFB), которые на VMFS создаются под нужды файловой системы для разных типов файлов. Суть самой проблемы в том, что иногда SFB кончаются, и VMFS запускает механизм конвертации LFB в SFB, но получившиеся SFB не становятся доступными сразу. Подробнее об этой механике рассказано в KB 87482.

Решением этой проблемы является только апгрейд вашей инфраструктуры на VMware vSphere ESXi 7.0 Update 3c.

Как знают многие администраторы, еще в прошлом году в ESXi 7 Update 2 компания VMware стала убирать различные настройки из основного конфигурационного файла esx.conf. Кстати, и не только оттуда. Например, раньше глобальные настройки FDM (он же HA - High Availability) хранились в файле /etc/opt/vmwware/fdm/fdm.cfg. Теперь их там тоже нет - они переехали во внутреннее хранилище ConfigStore, работать с которым нужно с помощью утилиты командной строки configstorecli.

То же самое произошло и с NTP - теперь настройки времени, хранящиеся в /etc/ntp.conf (для NTP) и /etc/ptp.conf (для PTP), недоступны для редактирования через файлы конфигураций. Кстати, если вы не знаете, чем NTP отличается от PTP, у нас есть отличная статья на эту тему (а вот тут - о поддержке PTP в vSphere 7 Update 2).

Более того, теперь все файлы каталога /etc помечены как только для чтения и не сохраняют своих изменений при перезагрузке!

Так что работать с большинством настроек теперь нужно через ConfigStore. В частности, для NTP и PTP есть 2 основных команды, которые взаимодействуют с ConfigStore для конфигурации времени:

• Получение настроек времени

# esxcli system ntp get
# esxcli system ptp get

• Установка настроек времени

# esxcli system ntp set
# esxcli system ptp set

Если вы хотите узнать список всех конфигурационных файлов, которыми теперь заведует ConfigStore, можно выполнить следующую команду в консоли ESXi:

# configstorecli files get

Как многие из вас знают, в ноябре прошлого года компания VMware отозвала обновление платформы vSphere 7 Update 3 из-за критических ошибок. Это были проблемы с выпадением в PSOD, трудности при апгрейде с прошлых версий, неполадки в плане стабильности vSphere HA и другое.

В конце декабря мы напомнили о том, что проблема существует уже месяц, а VMware все никак не может решить ее. Основная информация о возникшей ситуации с последним пакетом обновлений публиковалась в KB 86398. Там же можно узнать, что вся линейка Update 3/3a/3b была отозвана из-за критических проблем, описанных в KB 86287 и KB 86281.

Теперь VMware объявила о выпуске окончательной версии VMware vSphere 7 Update 3c, где все должно работать как надо (однако бежать обновляться прямо сейчас мы бы не рекомендовали:)

Также сообщается, что в новом релизе решены все проблемы с безопасностью, касающиеся уязвимости Log4j, которая затронула большое количество систем. Эта уязвимость позволяла злоумышленнику, который имел доступ к отсылке логов (самих сообщений или к настройке их параметров), исполнять код, полученный с LDAP-серверов, когда настройка message lookup substitution включена.

Наконец-то были обновлены основные компоненты продукта, ESXi и vCenter, а также опубликован список известных проблем и их обхода:

• vSphere ESXi 7 Update 3c Release Notes
• vCenter Server 7 Update 3c Release Notes
• vSphere 7 Update 3c – List of Known Issues and Workarounds

О новых возможностях основного vSphere 7 Update 3 вы можете почитать у нас тут, их список не изменился. Скачать все компоненты платформы, включая ESXi 7 Update 3c и vCenter Server 7 Update 3c, вы можете по этой ссылке.

Некоторые из вас, вероятно, знают такой сайт virten.net, где в свое время публиковалось много интересных технических статей об инфраструктуре VMware. Автор этого ресурса делает много интересных вещей, например, средство PowerShell OVF Helper.

OVF Helper - это репозиторий шаблонов для развертывания ВМ из виртуальных модулей (Virtual Appliances) в формате OVF, которые основаны на рабочем процессе развертывания в мастере создания машин vSphere Client. Через OVF Helper вы таким же образом соединяетесь с vCenter Server, заполняете нужные переменные и выполняете сценарий развертывания. Это точно так же просто, как и при использовании vSphere Client, но плюс в том, что вы можете использовать этот сценарий повторно, не проходя вручную шаги мастера клиента vSphere.

Также настроенные параметры в скрипте будут вам отличным напоминанием о том, какую конфигурацию вы использовали для виртуальных модулей.

На данный момент доступны сценарии для следующих продуктов и их версий:

• VMware NSX-T 3.2 | 3.1 | 3.0 | 2.5 | 2.4
• VMware NSX Advanced Load Balancer
• VMware NSX for vSphere 6.x
• VMware Cloud Director 10 | 10.2 | 10.3
• VMware vRealize Operations Manager 8.1
• VMware vRealize Orchestrator 8.1
• VMware vSphere Integrated Containers
• VMware ESXi Virtual Appliance
• VMware Photon OS 3.0 (cloud-init)
• VMware Event Broker Appliance 0.7

Также на странице PowerShell OVF Helper размещены ссылки на OVA-модули, которые рекомендуется использовать совместно с соответствующей версией сценария.

Кстати, обратите внимание на раздел Tools на сайте автора - там много чего интересного:

Компания VMware объявила о выпуске новой версии Photon OS 4.0 rev 2. Напомним, что четвертая версия этой ОС, на базе которой построены виртуальные модули (Virtual Appliances) VMware, вышла в марте прошлого года.

Давайте посмотрим, что нового появилось в этом обновлении:

• Поддержка OpenSSL 3.0 - теперь этот протокол используется по умолчанию
• Новая утилита pmd-nextgen (photon management daemon), которая дает следующие возможности:
  • Удаленное управление системой с поддержкой мобильных устройств
  • Управление сервисами systemd и другими аспектами Photon OS через REST API
  • Использование REST API для конфигураций в реальном времени и тюнинга производительности, а также мониторинга состояния Linux-систем
• Доработки движка реального времени:
  • Улучшения при работе с низкими задержками (low-latency), а также уменьшение джиттера (OS jitter)
  • Повышение стабильности работы и улучшения средств отладки
• Прочие улучшения:
  • Доработки и багофиксы в tdnf
  • Поддержка GNU tarfs для ядра Linux-esx
  • Поддержка eBPF для ядра Linux
  • Улучшения установщика, такие как поддержка устройства Secondary Kickstart и пользовательских настроек монтирования устройств
• Обновления пакетов:
  • Linux kernel 5.10.83
  • Glibc 2.32
  • Systemd 247.10
  • Python3 3.10.0
  • Openjdk : 11.0.9
  • Openssl : 3.0.0
  • Cloud-init: 21.4

Скачать Photon OS 4.0 rev 2 можно в ISO-дистрибутивах для платформ x86_64 и arm64, а также в формате OVA как виртуальный модуль для платформы VMware vSphere. Там же доступны кастомизированные образы Amazon AMI, Google GCE, Azure VHD, а также образ для Raspberry Pi.

Первое в этом году обновление на сайте проекта VMware Labs - это очень полезное мобильное приложение VM News Collector. Оно представляет собой агрегатор всех новостей и обновлений о продуктах и технологиях компании VMware, который собирает все это в реальном времени.

На айфоне это выглядит так:

На андроидах - примерно так же:

VM News Collector построен на базе фидов RSS, которые добавляются из различных источников и сейчас подключены на платформе VMware Blogs.

В приложении будет информация об обновлениях, патчах, существующих проблемах и вариантах их обхода. Важные оповещения будут работать на базе пуш-уведомлений. Также заявляется, что VM News Collector будет оповещать пользователей о критических уязвимостях в различных продуктах VMware, описание которых также можно будет посмотреть в разных источниках.

Пользователь сам может выбрать, в каких категориях ему получать уведомления и видеть их в своей ленте:

Полезной возможностью продукта является функция поиска новостей и оповещений для конкретного продукта VMware.

Скачать VMware VM News Collector для iOS и Android можно по этой ссылке.

В конце ноября мы писали о том, что "уже 5 дней VMware находится в состоянии экстренной починки VMware vSphere 7 Update 3", но ситуация оказалась гораздо хуже. Никаких новостей об исправлениях для новой версии, по-прежнему, нет. Напомним, что о новых возможностях vSphere 7 U3 мы писали тут.

Основная информация о возникшей ситуации с последним пакетом обновлений приведена в KB 86398. Там можно узнать, что вся линейка Update 3/3a/3b была отозвана из-за критических проблем, описанных в KB 86287 и KB 86281. На странице загрузки VMware vSphere, по-прежнему, висит красный баннер и релиз Update 2a от апреля этого года:

Среди найденных багов - и выпадение в PSOD, и проблемы апгрейда с прошлых версий, и проблемы со стабильностью vSphere HA, и многое другое, судя по заметкам в некоторых блогах:

Если мы зайдем на статью базы знаний "Build numbers and versions of VMware ESXi/ESX (2143832)", то увидим, что последние три релиза vSphere просто зачеркнуты в таблице:

18 ноября зачеркнутые в таблице релизы были удалены из VMware Customer Connect, а новостей по поводу сроков исправления проблем с этого времени не было. Сама VMware пишет в KB вот так:

Надо отметить, что VMware vCenter 7 Update 3 и Update 3a сейчас доступны для скачивания и использования в производственной среде.

В самом интересном положении оказались пользователи, которые уже прошли процедуру апгрейда своей инфраструктуры на Update 3. Им не рекомендуют откатывать все назад (это и не так просто, к тому же), если они не сталкиваются с критичными проблемами, такими как PSOD. Однако и сроков по доступности исправлений Update 3 тоже не дают.

Ждем исправлений!

Как знают многие администраторы VMware vSphere, у компании есть очень полезный документ "Security Configuration Guide", который представляет собой основное руководство по обеспечению безопасности виртуальной среды. Последняя версия этого документа содержит 87 настроек (мы писали об этом тут), так или иначе влияющих на безопасность как самой платформы виртуализации, так и виртуальных машин и их гостевых операционных систем.

Документ передает концепцию "Secure by design", что означает, что среда VMware vSphere изначально настроена оптимальным образом с точки зрения безопасности, поэтому вносить изменения вам нужно только в случае наличия каких-либо специальных требований именно в вашей инфраструктуре.

Надо понимать, что конфигурация виртуальной среды в целях обеспечения повышенной (относительно дефолтной) безопасности - это всегда компромисс между защищенностью и удобством использования (как и для любой другой ИТ-системы). Из коробки сама платформа, сервер vCenter и виртуальные машины настроены таким образом, чтобы обеспечить максимальное удобство использования при должном уровне безопасности.

Помните, что изменение настроек безопасности - очень опасная штука, которая требует обязательного документирования и оповещения администраторов об этом. Ведь из-за этого они могут получить проблемы с работой отдельных компонентов, но так и не понять их источника, что будет похуже чисто гипотетической маловероятной атаки, связанной с измененной настройкой.

Сегодня мы посмотрим на 15 действительно полезных рекомендаций и настроек, применение которых не сильно снизит удобство использования, но при этом даст чуть более высокий уровень безопасности, что может оказаться вам в каком-то случае полезным.

Структура списка конфигураций и рекомендаций

Давайте сначала взглянем на колонки Excel-таблицы, которая, по-сути, и является списком настроек и рекомендаций, которые вы можете применить в своей виртуальной инфраструктуре:

• Guideline ID - идентификационное имя рекомендации.
• Description - лаконичная формулировка сути этой рекомендации.
• Discussion - описание влияния настройки на конфигурацию среды и операции, а также обсуждение моментов, которые касаются удобства использования инструментов управления в связи с изменением настройки.
• Configuration Parameter - это название расширенной настройки соответствующего компонента, которую вы можете изменить. Понятно дело, что эта колонка заполнена не всегда, так как есть рекомендации, которые регулируются не конкретными настройками, а, например, топологией или подходом к организации среды.
• Desired value - рекомендуемое значение, часто оно является значением по умолчанию, если это не site specific.
• Default value - то значение, которое установлено по умолчанию.
• Is Desired Value the Default? - просто для понимания (и для референса в будущем), установлено ли желаемое значение по умолчанию.
• Action Needed - это тип действия, который необходимо предпринять - изменить настройку, проверить конфигурацию или топологию, добавить или удалить что-то и т.п.
• Setting Location in vSphere Client - очень полезная колонка, позволяющая вам найти нужную настройку в клиенте vSphere.
• Negative Functional Impact in Change From Default? - это как раз информация о влиянии на функционал в случае изменения настройки.
• PowerCLI Command Assessment - команда PowerCLI, с помощью которой можно узнать текущее значение настройки.
• PowerCLI Command Remediation Example - команда PowerCLI по применению настройки.
• Hardening - указывает на то, что это действительно настройка, которой нужно уделить внимание при конфигурации.
• Site Specific Setting - говорит о том, что задать конфигурацию должен сам пользователь, в зависимости от его окружения.
• Audit Setting - указывает, что вам необходимо время от времени проверять эту настройку, чтобы убедиться, что значение по умолчанию не было изменено необоснованно.

Само руководство разбито на 4 категории, которые понятны всем администраторам:

• Хосты ESXi
• Сервер vCenter
• Виртуальные машины
• Гостевые ОС виртуальных машин

Также в документе есть и вкладка "Deprecated" - там находятся те настройки, которые больше не актуальны. Что важно - там помечено, почему это случилось (в колонке Discussion).

Итак, давайте посмотрим на 15 самых интересных и, главное, полезных настроек, которые вы можете изменить, а также рекомендаций, которые вы можете выполнять, чтобы повысить безопасность виртуальной среды в своей инфраструктуре.

Хосты ESXi

• Configure remote logging - это действительно правильная рекомендация. Хосты ESXi должны отправлять свои логи на удаленный сервер Syslog. Самый удобный вариант - это использовать в качестве Syslog-сервера решение VMware vRealize Log Insight. Ведь если злоумышленник проникнет на сервер ESXi, то после своей активности он эти логи удалит, и расследовать будет нечего. С централизованного внешнего сервера удалить эти данные сложнее. На работу виртуальной среды эта конфигурация не влияет.
• Ensure ESXi management interfaces are isolated on their own network segment - это очевидная, но не всегда выполняемая администраторами конфигурация. Конечно же, вся управляющая инфраструктура виртуальной среды должна находиться в выделенном сегменте сети в своих VLAN, куда имеют доступ только администраторы. То же самое касается и сети vMotion, и сети vSAN.
• esxi-7.shell-interactive-timeout и esxi-7.shell-timeout (Set a timeout to automatically terminate idle ESXi Shell and SSH sessions) - по умолчанию сессии командной оболочки и SSH-сессии висят постоянно, что, конечно же, представляет потенциальную угрозу. Лучше ограничить таймаут 600 секундами, чтобы никто эти сессии не смог подхватить.
• Only run binaries delivered via VIB - эта настройка позволяет устанавливать бинарные компоненты только через VIB-пакеты, которые соответствуют установленному Acceptance Level. Если вы не пользуетесь посторонними библиотеками кустарного производства, то лучше эту настройку включить. Когда вам понадобится установить такой бинарник - просто включите эту настройку снова. Но это изменение лучше задокументировать.
• Enable bidirectional/mutual CHAP authentication for iSCSI traffic - настраивать CHAP-аутентификацию нужно обязательно, чтобы предотвратить атаки, связанные с перехватом трафика к хранилищам. Настраивать это недолго, но зато будет больше уверенности в сохранности данных.

Сервер vCenter

• Ensure vCenter Server management interfaces are isolated on their own network segment or as part of an isolated ESXi management network - это та же самая рекомендация по изоляции управляющей сети от сети виртуальных машин, что и для серверов ESXi. Убедитесь, что они надежно разделены с помощью VLAN и других техник.
• Ensure that port mirroring is being used legitimately - эта настройка отключена по умолчанию, но зеркалирование трафика на портах vSphere Distributed Switch надо периодически проверять (vSphere Client -> Networking -> Distributed Switch -> Configure -> Settings -> Port Mirroring). Такой способ атаки - один из самых простых в реализации, если у злоумышленника есть доступ к настройкам VDS (обычно в них никто не заглядывает после первичной настройки). То же самое касается и отправки трафика NetFlow, управление которым производится в разделе vSphere Client -> Networking -> Distributed Switch -> Configure -> Settings -> NetFlow.
• Limit access to vCenter Server by restricting DCLI / SSH - это разумная рекомендация, чтобы злоумышленник не смог залогиниться в консоль виртуального модуля напрямую или по SSH. Уменьшив поверхность атаки, вы сделаете среду более защищенной. Только не забудьте задокументировать это изменение.
• Configure File-Based Backup and Recovery - не ленитесь настраивать и обслуживать бэкап конфигурации вашего управляющего сервера. Однажды это может вам пригодиться как в контексте безопасности, так и в контексте быстрого восстановления системы управления в виртуальной инфраструктуре в случае сбоя.
• Configure remote logging - здесь те же рекомендации, что и для ESXi. Не ленитесь настраивать сервер удаленного сбора логов.

Виртуальные машины

• Limit the number of console connections - очень часто к консоли виртуальной машины не нужно больше одного подключения ее администратора. В этом случае дефолтное количество 40 одновременных подключений лучше уменьшить до 1. Делается это в разделе VM -> Edit Settings -> VM Options -> VMware Remote Console Options.
• Encrypt VMs during vMotion - это полезная настройка. По умолчанию, трафик vMotion шифруется, только если есть такая возможность (Opportunistic). Если у вас хватает вычислительных ресурсов и быстрая сеть, то можно установить это значение в "Required". Это обеспечит защиту от перехвата трафика vMotion, в котором есть данные гостевой ОС виртуальной машины.
• Lock the VM guest session when the remote console is disconnected - лучше включить эту настройку и лочить сессию при отключении удаленной консоли, чтобы брошенная администратором сессия в гостевой ОС виртуальной машины не была подхвачена злоумышленником. На удобство работы это не сильно влияет. Изменить эту настройку можно в VM -> Edit Settings -> VM Options -> VMware Remote Console Options.

Гостевая ОС

• Ensure that VMware Tools are updated - это просто еще одно напоминание, что нужно постоянно следить за тем, что пакет VMware Tools обновлен до последней версии (и желательно поддерживать единый уровень версий для всех машин). В нем содержится много компонентов (кстати, не устанавливайте ненужные), поэтому уязвимость в одном из них может скомпрометировать множество виртуальных машин. То же самое относится и к версии Virtual Hardware - следите за этим.
• Disable Appinfo information gathering - об интерфейсе Appinfo мы писали вот тут (он же Application Discovery). Он позволяет, например, собирать информацию о запущенных приложениях внутри гостевой системы и их параметрах. Механизм Appinfo используется различными решениями, такими как vRealize Operations Manager, для мониторинга на уровне гостевой ОС. Если же вы не используете эти решения в своей виртуальной среде, то данный механизм лучше просто отключить через VMware Tools. Учитывая какое количество багов, касающихся безопасности, в последнее время находится в различных компонентах инфраструктурного ПО, лучше отключить функции Appinfo, которые включены по умолчанию для всех гостевых ОС после установки VMware Tools.

Конечно же, в документе vSphere 7 Security Configuration Guide есть много и других настроек и конфигураций, изменение которых помогут вам повысить уровень безопасности. Иногда это связано с требованиями регулирующих органов или спецификой внутренних политик организации. Поэтому обратите особенное внимание на те конфигурации, которые помечены как Site Specific, а также те, где рекомендуемые значения отличаются от дефолтных. И обязательно документируйте сделанные изменения, а также проводите регулярный аудит наиболее важных настроек.

Компания VMware сообщает пользователям, что разобралась с проблемой, которая появилась в компоненте веб-сервера Apache Software Foundation log4j Java logging, а значит и во многих продуктах VMware. Эта уязвимость описана в CVE-2021-44228 - атакующий, который имеет доступ к отсылке логов (к отсылке самих сообщений или к настройке их параметров), может исполнять код, полученный с LDAP-серверов, когда настройка message lookup substitution включена. Это уязвимость типа "zero-day", а значит исправление ее еще находится в процессе.

Надо понимать, что поскольку проблема с log4j касается веб-серверов, то вам надо позаботиться о защите не только управляющих компонентов виртуальной инфраструктуры VMware, но и виртуальных и физических машин.

Итак, вот какие ресурсы помогут вам защититься от этой уязвимости:

• VMware Security Advisory VMSA-2021-0028 (главное описание проблемы и путей ее решения)
• VMSA-2021-0028 Questions & Answers (вопросы и ответы)
• VMSA-2021-0028 & Log4j: What You Need to Know (источник этого поста)
• VMware Communities Thread On CVE-2021-44228 (место, где можно задать вопросы по этой теме)
• Tips for Patching VMware vSphere & Cloud Infrastructure (практические советы по патчингу)
• VMware vSphere Security Configuration Guide (основной документ о безопасности vSphere)

Для инфраструктурного ПО VMware нужно просто убедиться в том, что у вас установлен соответствующий патч или апдейт, который не старше версии, указанной в таблице по первой ссылке:

Увы, для многих продуктов исправлений еще нет, они в процессе выпуска, поэтому до момента их накатывания следует озаботиться применением воркэраундов из рекомендаций VMware, ссылки на которые также приведены в таблице. Да, пока придется править реестр и конфигурационные файлы.

Помните, что уязвимость критическая и имеет оценку 10 из 10 по методике CVSS 3.1 (remote code execution, RCE), поэтому надо проверить все компоненты инфраструктуры уже сегодня, особенно те, что смотрят в интернет. Самым простым способом для злоумышленника будет посылка кода со страницы логина атакуемого сервиса, так как все такие действия логируются.

Ну и есть положительный момент - в облачных инфраструктурах, таких как VMware Cloud on AWS, эти проблемы уже устранены, но на стороне онпремизных облаков или небольших сервис-провайдеров они все еще могут быть.

Продолжаем рассказывать вам о продуктах компании StarWind, которая является одним из лидеров в сфере производства программных и программно-аппаратных хранилищ виртуальных машин на платформах VMware vSphere и Microsoft Hyper-V. Сегодня мы расскажем о бесплатной утилите V2V Converter / P2V Migrator, которая позволяет делать три важных для администратора вещи...

Как все из вас знают, не так давно компания VMware выпустила обновление своей серверной платформы виртуализации vSphere 7 Update 3. Мы писали также о нововведениях в отношении хранилищ, обновлении 3a, новых возможностях продукта vSAN 7 U3 и обновлениях vCenter и vSphere Client.

Сегодня мы поговорим об улучшениях в плане производительности платформы VMware vSphere 7 Update 3, о которых рассказано в обновившемся недавно документе "What’s New in Performance for VMware vSphere 7?". О похожем документе о производительности платформы vSphere 7 Update 2 мы писали в начале осени тут.

Давайте посмотрим, что нового в vSphere 7 U3 в плане производительности:

1. Масштабируемость виртуальных машин

Теперь максимальные параметры ВМ, доступных в vSphere выглядят так:

2. Оптимизации рабочих нагрузок, чувствительных к задержкам

Гипервизор VMware ESXi был еще больше оптимизирован, чтобы быстрее исполнять приложения, чувствительные ко времени отклика и задержкам (ultra-low-latency applications), уменьшены jitter и interference для приложений реального времени. Для этого было сделано множество оптимизаций в плане обработки прерываний. Чтобы воспользоваться этой функцией (low-latency mode) ее надо включить в BIOS машины.

3. Технология vSphere Memory Monitoring and Remediation (vMMR)

Размер памяти DRAM влияет на 50-60% стоимости самого сервера. При этом 1TB DRAM - это уже 75% этой стоимости. Поэтому VMware давно борется с этим, и одна из возможных оптимизаций здесь - использование Intel Optane Persistent Memory Mode, когда железо использует DRAM как кэш и представляет PMem как основную память системы. PMem более дешевая технология, но имеет побольше задержки (latency).

С помощью vSphere Memory Monitoring and Remediation (vMMR) можно следить за работой памяти в режиме Intel PMem Memory Mode и получать алерты когда ESXi исчерпывает память DRAM, что может привести к падению производительности сервера.

4. NVMe over TCP/IP

В релизе vSphere 7.0 была анонсирована поддержка технология NVMe over Fabrics, где первоначально поддерживались только протоколы FC и RDMA. Теперь же поскольку SSD-хранилища продолжают набирать популярность, а транспорт Non-Volatile Memory Express (NVMe) стал стандартом для многих типов систем, в vSphere 7 Update 3 появилась поддержка и NVMe over TCP, которая позволяет использовать стандартную инфраструктуру TCP/IP, оптимизированную под Flash и SSD, для трафика хранилищ. Это поможет в некоторых случаях существенно сэкономить на оборудовании при поддержании высокого уровня производительности.

Больше подробностей о производительности VMware vSphere 7 вы найдете в документе "What’s New in Performance for VMware vSphere 7?".

Многие из вас заметили, что на сайте VMware обновление vSphere 7 Update 3 пока не скачать. При входе на страницу загрузки VMware vSphere показывают красное предупреждение, которое говорит о том, что проблема нового апдейта весьма серьезная:

Скачать VMware vSphere 7 Update 3 и ее компоненты сейчас нельзя.

Ситуация продолжается уже 5 дней, а VMware не дает конкретных сроков устранения проблемы. При этом пользователям, которые уже провели апгрейд до vSphere 7 Update 3, 3a или 3b - неясно пока, что делать. Нам в комментариях уже писали о том, что сталкиваются с серьезными проблемами при апгрейде на U3 и после этого.

Основная информация о возникшей проблеме приведена в KB 86398. Там можно узнать, что вся линейка Update 3 была отозвана из-за критических проблем, описанных в KB 86287 и KB 86281.

Прямо скажем - проблем этих много, и просто удивительно, как все это прошло выходной контроль при выпуске релизов третьего пакета обновлений. Это и выпадение в PSOD, и проблемы апгрейда с прошлых версий, и проблемы со стабильностью vSphere HA, и другое:

Следим за развитием событий, FAQ в KB 86398 не дает никакой ясности по планируемому времени исправления проблемы. Пользователям, обновившимся до vSphere 7 Update 3, не рекомендуют откатываться до предыдущей версии, если они не сталкиваются с серьезными проблемами в функционировании инфраструктуры.

Помните, любое обновление продуктов VMware надо проводить только по прошествии нескольких недель, в течение которых нужно следить за появившимися сообщениями о серьезных багах. Эта ситуация повторяется из релиза в релиз, а опытные пользователи vSphere к такому образу действий уже привыкли.

В начале осени, в рамках прошедшей конференции VMworld 2021 Online, компания VMware представила свое виденье развития концепции виртуализации и агрегации хранилищ корпоративных инфраструктур - Federated Storage Platform (FSP).

Проблема современного подхода к организации хранилищ состоит в том, что аппаратные комплексы в датацентре представлены разными моделями, производителями, а также поколениями в рамках одной продуктовой линейки. Ввиду этого администраторам приходится разрабатывать набор административных регламентов по обслуживанию жизненного цикла таких хранилищ - ввод в эксплуатацию, развертывание новых сервисов, обеспечение высокой доступности и план по изменению емкостей - вывод устаревших систем и расширение существующих емкостей. Ко всему этому добавляются Day-2 Operations и обеспечение безопасности хранения данных виртуальных и физических сред.

Как итог - корпоративная инфраструктура предприятия не может обеспечить те же преимущества, что и унифицированная облачная среда, которая избавляет администраторов от заботы об оборудовании и, в частности, хранилищах.

Проблему отчасти решает подход к организации гиперконвергентной инфраструктуры (Hyperconverged Infrastructure, HCI), например, концепция HCI Mesh. Но этого было недостаточно, и VMware запустила радикальную инициативу - Federated Storage Platform (FSP) - решение, которое приведет к унификации операций онпремизных и облачных сред в плане хранилищ за счет их виртуализации и агрегации.

С помощью VMware FSP можно будет управлять любым числом хранилищ разных вендоров, с которыми работает любое количество управляющих серверов vCenter:

Здесь будет 2 ключевых сущности:

• Common volumes - это новый слой представления ресурсов хранения от гетерогенных кластеров vSAN, томов vSphere Virtual Volumes дисковых массивов, а также NFS-массивов. Все это будет объединено на уровне пулов.
• Data center control plane - новый слой управления инфраструктурой хранения на базе эластичных пулов с возможностью полного доступа к имеющимся емкостям. Все это позволит видеть ресурсы хранения как в облаке, безотносительно имеющихся моделей массивов и топологий.

FSP будет полностью интегрирован в уже имеющимся механизмом политик хранения SPBM (vSphere Storage Policy Based Management), предоставляя гибкие пулы хранения для уровня приложений на базе их потребностей. Платформа VMware vSphere будет выступать как один из потребителей ресурсов в рамках этой концепции.

Для обеспечения различных уровней сервиса будут работать расширенные политики FSP, такие как квоты на емкости и ограничения по производительности, чтобы обеспечить ярусность хранения и работы с данными.

В рамках FSP процесс добавления или списания хранилищ будет бесшовным, то есть не вовлекать физическую коммутацию, которая будет выводиться за рамки процесса управления единым пулом хранилищ. Например, FSP может автоматически обнаружить новое уже подключенное хранилище, после чего добавить его в общий federated пул и начать балансировку нагрузок посредством VMware vSphere Storage vMotion.

Сейчас администраторам приходится вручную выполнять операции SVMotion для ввода новых хранилищ в эксплуатацию и их вывода, а FSP будет делать все это автоматически в "lazy"-режиме, чтобы обеспечивать уровень производительности виртуальной среды.

FSP будет интегрирована с драйвером vSphere CSI в Kubernetes, а также технологией CNS (Cloud Native Storage). Разработчики смогут потреблять дисковые емкости в рамках классов через FSP, а администраторы получать полную видимость использования таких хранилищ на уровне всего датацентра.

Сейчас решения VMware vSphere with VMware Tanzu и TKG-S VMware Tanzu Kubernetes Grid могут развертывать рабочие нагрузки в рамках пространств имен кластера, а FSP даст возможность развернуть приложения на любом хранилище в любом кластере на базе любых доступных политик.

Сейчас с помощью x-vMotion виртуальную машину можно перемещать между кластерами и разными инфраструктурами vSphere. FSP расширит эти возможности, позволяя виртуальным машинам и контейнеризованным приложениям свободно "путешествовать" между кластерами, инфраструктурами и пространствами хранения - при этом под полным контролем управляющего слоя.

Получить больше информации об инициативе можно из записи этой ссессии с прошедшего VMworld 2021 Online: VMware’s vision for storage and data in a multi-cloud world.

Какое-то время назад мы писали о возможностях платформы виртуализации VMware vSphere 7 Update 3, где появилось немало всего нового. Но, помимо заметных нововведений, было сделано немало и небольших улучшений, которые влияют на удобство использования vSphere Client для управления серверами VMware vCenter.

Давайте посмотрим на интерфейс рекомендаций VMware DRS в VMware vSphere 7 Update 2 и ниже, который находится вот тут: Cluster UI > Monitor > DRS Recommendations:

Видно, что интерфейс был так себе, поэтому в Update 3 его переделали:

Теперь в гриде мы видим список действий для данной рекомендации, появились элементы Select All и Clear Selection, ну и в целом все стало выглядеть намного приятнее.

Также это хорошо смотрится и в темной теме vSphere Client:

Кроме того, было улучшено и окно настройки механизма Proactive HA. Раньше оно выглядело вот так:

Это было довольно ненативно - нясно, включен ли соответствующий провайдер, и какие условия для него работают. Теперь же отдельным переключателем включается провайдер:

А когда он включен, соответствующими переключателями можно настраивать условия отказов:

При этом доступны и операции над всеми переключателями - Block All и Unblock All.

На самом деле, подобные улучшения происходят часто и в минорных релизах VMware vSphere - команда UI в VMware постоянно старается сделать жизнь администраторов проще и приятнее.

На сайте проекта VMware Labs появилось еще одно полезное средство для администраторов виртуальной инфраструктуры - vSphere Diagnostic Tool. Оно представляет собой python-скрипт, который запускает диагностические команды на виртуальном модуле Photon OS (на его базе построен, например, vCenter Server Appliance), а также в перспективе это будет работать и в среде VMware ESXi.

Основное назначение данной утилиты - дать администраторам быстрое средство траблшутинга, которое они могут использовать для первичной идентификации наиболее распространенных проблем. Если все проверки пройдут успешно, то дальше уже можно более глубоко изучать логи и проводить дополнительные тесты.

Интересно, что данный продукт уже был протестирован во внутренней команде поддержки VMware, которая опробовала его на реальных пользователях.

Для vCenter Server Appliance 6.5 или более поздней версии можно выполнить следующие тесты:

• Базовая информация о vCenter
• Проверка Lookup Service
• Проверка AD
• Проверка сертификатов vCenter
• Проверка основных файлов (Core File)
• Проверка диска
• Проверка vCenter DNS
• Проверка vCenter NTP
• Проверка портов vCenter
• Проверка аккаунта Root
• Проверка служб vCenter
• Проверка механизма VCHA

В качестве результатов будет выдан один из статусов Pass/Warning/Fail, а также для статусов Warning и Fail выводятся ссылки на статьи KB, которые могут пригодиться для решения проблем в данной категории.

Команда заявляет, что в бэклоге проекта еще более 100 планируемых фич, поэтому следите за обновлениями скриптов. Скорее всего, данное средство включат в будущем в состав инфраструктурных продуктов линейки VMware vSphere для проверки виртуальных модулей на базе Photon OS (а это уже почти все продукты, построенные на базе хостовой ОС Linux, вроде vCSA).

Скачать vSphere Diagnostic Tool можно по этой ссылке.

Ковид и карантин надоели - надо встречаться офлайн (с соблюдением всех мер, конечно же). Поэтому ежегодный VMware vForum Russia возвращается. Впервые он пройдет в гибридном формате!

25 ноября все желающие бесплатно могут посетить мероприятие VMware vForum - встречайтесь offline в Москве и online – по всему миру! Конференция пройдет на русском языке.

Место проведения: отель InterContinental, ул. Тверская 22
Начало в 11:00

VMware vForum – это лучший повод, чтобы встретиться и обсудить последние тренды ИТ-отрасли, а также узнать о последних новинках, представленных на глобальной конференции VMworld.

Вас ждет много интересного:

• 4 тематических блока – ИТ-инфраструктура и мультиоблачные среды, модернизация приложений, “работа где угодно”, сети и безопасность
• Истории заказчиков из различных отраслей в формате панельных дискуссий
• Выступления от ведущих экспертов VMware и топовых амбассадоров ИТ-рынка
• Онлайн трансляция на все регионы
• Розыгрыш призов

Скачать полную программу мероприятия вы можете по этой ссылке.

Зачем вам следует посетить vForum:

• Найти контент, который подходит именно вашей специализации
• Прокачать свои знания современных трендов в области цифровизации бизнеса
• Получить консультации и назначить личные встречи с экспертами VMware
• Получить помощь при выборе решения, которые подходят именно для вашей компании в том объеме и формате как вам необходимо

Регистрируйтесь на VMware vForum в Москве бесплатно здесь.

Недавно компания VMware провела тестирование баз данных PostgreSQL в качестве рабочей нагрузки в виртуальных машинах vSphere 7.0 U2 с использованием памяти Intel Optane DC persistent memory (PMem). Напомним, что именно на этот тип памяти компания VMware ориентируется при разработке технологии Project Capitola.

Память Intel Optane DC persistent memory (DCPMM она же PMEM) не такая быстрая как DRAM и имеет бОльшие задержки, но они все равно измеряются наносекундами. При этом данная память позволяет иметь ее большой объем на сервере, что существенно повышает плотность ВМ на одном хосте.

В качестве тестового стенда использовалась следующая конфигурация хоста ESXi и виртуальных машин:

Память PMEM была презентована виртуальным машинам как очень быстрое устройство хранения (NVDIMM). Конфигурация PostgreSQL была следующей:

VMware использовала 3 различных конфигурации для тестирования:

• 2 устройства NVME SSD (это базовый уровень) - оба раздела, WAL и база данных, были на двух разных быстрых SSD
• WAL на базе PMEM - раздел WAL поместили на 200-гигабайтное устройство PMem NVDIMM
• WAL и база данных на PMem - все разделы были размещены на устройствах PMem NVDIMM

В виртуальной машине запускали стресс-тест базы данных со значительной нагрузкой на диск, средней нагрузкой на систему и интегрированными транзакциями. Пропускная способность (throughput) измерялась в количестве транзакций в секунду (TPS).

Вот что из этого вышло:

По итогу теста для полной нагрузки на PMEM по сравнению с SSD пропускная способность выросла на 44.6%, а задержка (latency) упала на 30.8% (при перенесении только WAL на PMEM эти показатели составили 13.4% и 11.8%, соответственно).

Те же самые параметры для read-only транзакций:

Тут уже разница более, чем в 3 раза. Также VMware попробовала машину с 1 ГБ оперативной памяти вместо 200 ГБ - там улучшение было еще больше, а среднем PMEM дает улучшение производительности по сравнению с SSD в районе 4.5x.

Полное описание процедуры тестирования находится тут.